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ABSTRACT 

The  Naval  Postgraduate  School  is  developing  a  small, 
experimental,  low-orbit  packet  radio  satellite  for  launch  in 
1995.   It  is  the  first  for  use  by  the  amateur  radio 
community  to  implement  spread  spectrum  communications.   To 
aid  in  designing  the  spacecraft's  communications  network,  we 
have  developed  an  object-oriented,  reusable,  high  resolution 
simulation  model,  PACSIM,  which: 

•  fully  emulates  the  activity  of  users  in  the  network; 

•  has  the  ability  to  provide  information  on  these  measures 
in  several  thousand  different  scenarios. 

We  describe  this  satellite-user  network  and  elucidate  the 

strong  interdependence  of  design  factors.   Simulation 

results  are  presented.   Also,  we  critique  the  use  of 

simulation  as  a  decision  aid  for  assessing  the  effect  of 

design  decisions  such  as  data  transfer  rate,  spacecraft 

memory  allocation  for  store-forward  and  capture  protocol 

among  other  factors . 
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I.  NETWORK  DESCRIPTION 

A.   BACKGROUND 

The  Petite  Amateur  Navy  Satellite  (PANSAT)  is  a  small, 
low-orbit  spread  spectrum  communications  satellite  scheduled 
for  launch  in  1995.  It  is  designed  for  use  by  amateur  radio 
operators.  The  spacecraft's  orbit  is  expected  to  be  at  an 
altitude  between  450-800  kilometers,  at  an  inclination  of 
93.5°  and  a  maximum  slant  range  of  approximately  2  000  km. 
Users  on  the  ground  will  be  provided  with  a  view  of  the 
satellite  between  four  and  ten  minutes  in  duration.  The  size 
of  the  user  base  is  currently  unknown.  However,  the  fields  of 
spread  spectrum,  packet  radio  and  satellite  communications  are 
widely  used  among  amateur  radio  operators  and  attention  to 
this  program  has  grown. 

1.   Summary  of  session 

The  spacecraft  will  normally  be  in  receive  mode  until 
it  arrives  in  the  view  of  a  user's  ground  station  and  acquires 
the  pseudo-noise  coded  signal  from  it.  This  sequence  is  a  128 
bit  stream  and  is  transmitted  by  the  subscriber  until 
acquisition  is  achieved.  The  receiver  assesses  if  it  is 
following  the  sequence  in  synchronization  with  the  transmitted 
signal.  If  not,  it  "slides"  and  "looks"  again  to  determine 
whether  it  matches. 


The  communications  payload  of  PANSAT  is  designed  for 
a  central  frequency  of  437.25  Mhz  (960  Khz  bandwidth) .  Uplink 
and  downlink  will  be  done  within  this  bandwidth,  with 
information  relayed  in  bit  packets.  These  packets  are  stored 
and  retrieved  in  the  spacecraft  control  unit's  (SCU)  on-board 
processor.  Data  storage  and  retrieval  are  accomplished  using 
the  operators'  callsigns  as  references.  PANSAT  is  intended  to 
have  its  own  address  for  use  by  the  ground  control  station. 
Commands  for  the  satellite  are  envisioned  only  to  request 
experiment  data  and  provide  telemetry  and  performance 
information  to  the  control  station. 


B.   HIGH-LEVEL  DESCRIPTION 
1 .   General 

The  system  consists  of  uncoordinated  users  who  contend 
for  access  to  a  single  channel.  As  shown  in  Figure  1  these 
users,  also  called  subscribers,  are  located  at  ground  sites 
not  necessarily  covered  by  a 


single  orbit  of  the 
spacecraft .  Due  to  the 
periodicity  of  PANSAT' s  path, 
it  will  not  be  in  a  user's 
view  during  each  orbit. 

As   the   spacecraft 
comes  over  the  horizon,   a 


In  its  orbit,  PANSAT  will  periodically  pass  over  some  users 
but  not  others. 


subscriber    will    attempt  Figure  1    User     access     is     a 

function   of  PANSAT' s   orbit. 


communications  windows  due  to  the  low  orbit  of  the  satellite. 
Users  access  the  channel  by  locking-up,  or  synchronizing,  with 
the  satellite.  When  two  or  more  subscribers  simultaneously 
attempt  to  initiate  a  session  with  the  spacecraft,  there  are 
two  possible  results:  either  there  is  a  collision  or  one  will 
capture  the  server.  A  collision  results  in  unsuccessful 
attempts  for  both  users  and  requires  later  scheduled 
synchronization  transmission.  Tagged  to  the  end  of  the 
synchronization  is  a  preamble  identifying  the  user,  followed 
by  the  data  packet  along  with  its  routing  instructions,  called 
the  header. 

If  the  message  arrives  at  the  spacecraft,  the  SCU 

•  routes  the  message  for  the  appropriate  addressees  ; 

•  forms  a  queue  of  messages  stored  for  the  addressee  ; 

•  transmits,   or   downloads,   the   stored   traffic   after 
synchronizing  with  the  recipient,  . 

The  caller  then  requests  a  disconnect  and  the  satellite 

returns   to  a  ready  state,   awaiting  a  new  attempt   for 

synchroni  zat  ion . 

2 .   Channel  Access 

As  mentioned  above,  users  are  not  coordinated  by  a 

master  clock  nor  can  they  sense  whether  a  channel  is  being 

accessed  or  in  use.   The  only  information  provided  is  the 

starting  time  of  the  communications  window.   This  window  of 

time  reflects  the  interval  during  which  the  spacecraft  is  in 

the  view  of  a  user.   In  other  words,  the  low-earth  orbit  of 


the  view  of  a  user.  In  other  words,  the  low-earth  orbit  of 
the  satellite  provides  a  limited  horizon  on  the  ground.  As 
this  horizon,  or  footprint,  traverses  the  ground,  it  covers 
the  position  occupied  by  a  user.  The  period  from  initial 
coverage  in  the  footprint  to  termination  is  the  communications 
window. 

Due  to  the  absence  of  overall  network  control,  the 
occurrence  of  transmission  delay  and  an  array  of  other 
arbitrary  factors,  it  is  assumed  that  no  two  callers' 
synchronizing  signals  are  initiated  at  the  exact  same  time. 
However,  a  characteristic  of  this  transmission-driven  protocol 
is  that  the  synchronization  sequence  --  the  elements  of  which 
are  called  chips  --  is  sent  iteratively  until  the  SCU's 
receiver  achieves  a  lock  and  is  captured. 

If  another  attempt  occurs  such  that  its  sequence  is 
within  a  phase  difference  not  exceeding  the  duration  of  a 
single  chip,  the  SCU's  receiver  will  be  unable  to  distinguish 
between  the  signals  and  a  collision  results  (Pursely,  1987,  p. 
118)  .  A  collision  causes  a  failed  attempt  and  another  is  made 
after  a  delay.  If  there  is  sufficient  offset  between  two 
synchronization  streams,  then  one  will  be  successful, 
depending  upon  which  bit  stream  is  more  proximal  to  the 
pattern  expected  at  the  spacecraft's  receiver.  A  caller  is 
made  aware  of  an  unsuccessful  synchronization  if  during  the 
time  following  the  signal,  no  acknowledgement  or  subsequent 
message  transmission  is  received  from  the  satellite. 


3 .   Packet  Flow 

The  message  generated  by  the  user  is  subject  to  bit 
error,  associated  with  the  bit  error  rate  identified  in  the 
spacecraft  designers'  link  budget  analysis.  Occurrences  of 
bit  error,  which  are  not  independent  events,  may  signify  the 
loss  or  partial  destruction  of  a  packet.  This  is  unknown  to 
the  engaged  user.  After  accessing  the  channel,  the  user  will 
accept  a  synchronization  signal  from  the  spacecraft 
communicating  its  acknowledgement  of  receipt  of  the  user's 
packet  and  transmitting  traffic  addressed  to  the  engaged  user. 
If  this  is  not  detected  by  the  user,  a  new  transmission  is 
generated  in  order  to  ensure  receipt  of  the  apparently  lost 
traffic . 

After  the  subscriber  transmits  an  identification 
preamble,  the  spacecraft  attempts  synchronization.  There  is  no 
contention  for  the  current  user's  receiver  and  the  sequence  is 
followed  by  all  traffic  stored  by  the  spacecraft  control  unit. 
Finally,  the  subscriber  follows  with  an  acknowledgment  of 
receipt  of  the  down-linked  traffic  and  a  request  for 
disconnect.  The  SCU  recognizes  this  and  returns  to  a  ready 
state.  If  the  disconnect  request  is  not  received,  then  the 
SCU  times  out  and  retransmits  the  stored  traffic.  If  final 
acknowledgment  is  still  not  received  after  a  specified  period 
and  a  stipulated  number  of  retries,  the  spacecraft  returns  to 
a  ready  state. 


4 .   Packet  Storage  and  Forwarding 

This  aspect  of  message  transfer  occurs  in  the 
spacecraft.  Upon  arrival  of  a  packet  at  the  spacecraft,  it  is 
stored  until  the  SCU  is  accessed  by  the  addressee.  Several 
factors  bear  much  relevance: 


•  The  delay  in  message   forwarding   from  originator  to 
addressee  may  range  from  seconds  to  days. 

•  Message  size  is  of  arbitrary  length  although  the  maximum 
length  may  be  fixed  (Brachman,  1988,  p.  20)  . 

•  Packet  storage  capacity  of  the  SCU   is  finite. 

•  Messages  may  be  addressed  to  other  individual  subscribers, 
multiple  users  or  all  users. 


Due  to  storage  constraints,  as  the  number  of  users  increases, 
storage  may  become  scarce.  For  example,  if  a  packet  is 
addressed  to  a  group  of  users,  it  might  be  beneficial  to  store 
single  copies  of  messages  with  more  explicit  routing 
instructions  rather  than  a  single  copy  for  each. 

C.   NETWORK  DESIGN  DETAILS 

This  network  has  associated  with  it  several  design  issues. 
Channel  access  is  influenced  by  the  number  of  users  with  the 
spacecraft  in  view  concurrently  attempting  to  access  the  net, 
the  possibility  of  collision,  the  distribution  of  the  duration 
of  the  synchronizing  procedure  as  well  as  the  occurrence  of 
bit  error  and  resulting  retransmissions  of  data.  Data 
transfer  is  influenced  by  packet  length,  the  occurrence  of  bit 


error,  propagation  delay,  the  extent  of  error  detection  and 
correction  as  well  as  the  speed  of  the  SCU's  processor.  The 
store-and-forward  problem  is  affected  by  the  number  of 
subscribers,  packet  routing  instructions,  bit  packet  length, 
and  storage  capacity.  An  enumeration  of  specific  design 
questions  and  their  associated  measures  of  effectiveness  is 
provided  in  the  next  chapter. 
1 .   Channel  Access 

Given  the  absence  of  coordination  among  users,  it  is 
reasonable  to  assume  that  each  will  independently  initiate 
synchronization  attempts  in  accordance  with  some  arrival 
process.  An  outline  of  the  channel  access  process  is  shown  in 
Figure  2 . 

For  a  situation  in  which  a  geostationary  satellite  is 
involved,  users  have  continual  access  to  the  spacecraft.  In 
this  case,  the  model  may  achieve  an  equilibrium  in  which 
attempts  to  establish  communications  may  be  well  represented 
by  a  carefully  selected 
arrival  process.  However, 
because  many  users  are  aware 
of  the  time  at  which  the 
spacecraft  comes  into  view, 
the  first  attempts  by  each 
may  be  governed  by  a 
different   timing   algorithm 


Initially,  the  satellite  is  in  an  idle  state.  After  a  stisober  achieves  a 
lock,  the  server  transitions  to  a  busy  steis  during  whidi  period  it 
conducts  a  session  whti  the  current  user. 
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Figure  2       Contention        for 
channel   access. 


than  subsequent  bids,  depending  on  the  occurrence  of  a 
success.  After  "arriving,"  the  synchronization  process  takes 
place. 

When  in  the  ready  state,  the  SCU's  receiver  is 
continuously  scanning  the  spreading  sequence  for  the 
transmission  of  a  synchronization  signal.  This  is  a  128  bit 
sequence  which  is  transmitted  until  an  attempt  is  sensed.  At 
this  point,  the  receiver  compares  the  received  pseudo-noise 
sequence  with  the  expected 
progression  as  seen  through  the 
current  sequence.  If  there  is 
no  match,  then  the  receiver 
will  shift  its  scanning  of  the 
band  by  a  predetermined 
duration  of  time  and  compare 
again.      This   is   continued 


If  not  busy,  the  receiver  will  lock  on  during  one  of  them. 

1234  128 

I  I  I  I  1       Mill  ...I  1118 


Lock  will  be  achieved 
in  any  one  repetition 


In  faci  the  probability  is 
64/128,or0.5,  that  the 
receiver  is  captured  during 
the  first  64  tries. 


Figure  3    Illustration     of 
iteratively  until  the  receiver  the  synchronization  process. 

attains  a  lock.   The  characteristics  of  the  clocking  sequence 

of  the  pseudo-noise  generator  dictate  the  specific  quantity  of 

time  elapsed  during  this  process. 

Between  initiation  of  the  synchronizing  process  and 

the  capture  of  the  channel,  there  is  a  non-zero  probability  of 

collision.  The  occurrence  of  a  collision  is  a  function  of  the 

distribution  of  subscribers  initiating  simultaneous  attempts 

to  access  the  SCU  and  the  distribution  of  the  number  of 

repetitions  of  the  synchronizing  sequence  which  must  be 
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completed  to  achieve  lock  (Woerner,  1991,  p.  128)  .  Regardless 
of  the  collision  event,  multiple  users  attempting  to  access 
the  net  increases  the  effective  noise  in  the  RF  environment. 
Increased  noise  causes  a  deterioration  in  the  link  margin  and 
may  give  rise  to  increased  probability  of  bit  error  in  session 
transmissions . 

2.   Data  Transfer 

This  feature  of  the  network  is  affected  by  decisions 
regarding  packet  size,  error  detection  and  correction, 
acknowledging  message  receipt  and  the  establishment  of  a  half- 
or  full-duplex  channel. 

Decisions  concerning  packet  length  have  ramifications 
throughout  the  operation  of  the  network.  Regarding  packet 
transmissions  from  a  subscriber  or  from  the  spacecraft,  not 
only  do  longer  packets  require  a  greater  amount  of  time  for 
transmission  but  they  have  a  greater  probability  of 
experiencing  bit  error.  Furthermore,  the  length  of  packets 
impacts  the  SCU  storage  capacity.  Options  include 
establishing  fixed  message  lengths,  maximum  message  lengths 
with  variable  length  packets,  or  leaving  message  size 
unconstrained.  Each  of  these  considerations  may  be  viewed  in 
light  of  the  bit  error  rate.  Because  the  occurrence  of  bit 
error  is  not  independent  among  individual  bits,  the  greater 
the  size  of  the  bit  packet,  the  higher  the  probability  of  the 
packet  incurring  bit  error. 


The  worst-case  scenario  is  that  any  incident  of  bit 
error  results  in  the  loss  of  a  packet.  However,  unless  some 
error  detection  is  instituted,  the  absence  of  error  in  the 
message  header  is  satisfactory  for  a  message  to  be  received  at 
the  destination.  This  is  insufficient  for  reliable  networks 
(Tanenbaum,  1988,  p.  202).  To  institute  negative 
acknowledgements  requires  retransmissions  and  lengthens  the 
span  of  the  session.  However,  introduction  of  error 
correction  such  as  Hamming  codes  lengthens  the  packet  to  more 
than  three  times  its  original  length  (Tanenbaum,  1988,  p. 
208)  ,  and  would  also  be  very  likely  to  have  a  significant 
impact  on  the  duration  of  a  session. 

The  final  aspect  to 
be  discussed  in  analyzing  the 
network  data  transfer  is  the 
implementation  of  a  full- 
duplex  as  opposed  to  a  half- 
duplex  channel .  The  two 
scenarios   are   depicted   in 


■5CD 

disconnnects, 
awaiting  new 
synch  signal. 


afiow 
transmits 

synchronization 
signal  with  bit 
-  -  •  -•    -•-   — i 


User  transmits  an  ack 
for  stored  packets  and 
requests  disconnect 


* 


time 


Figures  4  and  5.   Regardless  Figure  4        Full    duplex 

communications  flow  between  SCU 
which    channel    type,  and  subscriber . 

subscribers    independently 

attempt  to  synchronize  with  the  spacecraft's  receiver.   Only 

if  successful  will  a  user  be  able  to  conduct  a  session  with 

the  SCU.   The  session  differs  conditioned  on  whether  or  not 

the  channel  is  full-  or  half -duplex. 
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In  full-duplex,  the  subscriber's  receiver  must  be  in 
lock  with  the  spacecraft's  transmitter  in  order  to  be  able  to 
conduct  a  session.  Once  both  caller  and  SCU  are  in 
synchronization,  communicated  by  the  user  as  a  connection 
request  and  by  the  spacecraft  as  an  acknowledgement,  data 
exchange  occurs.  While  receiving,  acknowledging  and  storing 
the  data  transmitted  by  the  active  user,  the  spacecraft 
retrieves  and  forwards  messages  addressed  to  the  active  user. 
If  the  packets  are  error-free  and  successfully  received  at 
either  end,  then  acknowledgements  are  dispatched  and  a 
disconnect  occurs.  However,  if  errors  are  detected  then 
negative  acknowledgements  are  sent  and  packets  are 
retransmitted.  Finally,  if  no  acknowledgements  are  received 
after  a  time-out,  then  the  packet  is  retransmitted. 

The  half-duplex 
session  is  more  involved 
because  after  each 
transmission,  communications 
are  stopped  and  the  other 
site  must  synchronize  in 
order  to  transmit 
acknowledgments  or  data. 
Specifically,  after  capturing 
the  SCU  and  completing  the 
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Figure  5        Half  duplex 

synchronization  signal,   the  communications  flow  between  SCU 

and  subscriber. 
active   user   transmits   the 
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data  packet.  Upon  broadcasting  the  packets,  the  user  ceases 
transmission  and  waits  a  period  of  time  commensurate  with  the 
transmission  duration  and  turn-around  time.  The  SCU  is 
expected  to  attempt  synchronization  and  transmit  an 
acknowledgement  and  any  mail  appropriately  addressed.  In  the 
case  of  error-free  receipt  of  the  stored  traffic,  the  user 
again  synchronizes  with  the  spacecraft's  receiver  in  order  to 
acknowledge  the  mail  and  request  disconnect.  Once  more,  the 
detection  of  bit  error  or  occurrence  of  time-out  will 
necessitate  retransmission;  however,  due  to  the  nature  of 
half -duplex  communications,  retransmissions  must  be  preceded 
by  a  synchronization  stream. 

During  the  course  of  these  synchronization  attempts 
with  the  SCU's  receiver,  the  spacecraft  will  need  to  prevent 
intervening  callers'  attempts  to  send  traffic  while  awaiting 
the  active  user's  synchronization  to  resume  the  session. 
3.   Store-Forward 

The  receipt  of  packets  by  the  SCU  initiates  the 
process  of  store-and-forward.  After  the  message  arrives,  it 
is  routed  to  storage  according  to  the  callsign  of  the 
addressee.  Packets  currently  in  storage  and  addressed  to  the 
current  user  are  retrieved  and  transmitted.  This  process  is 
shown  in  Figure  6.  Issues  of  interest  include  message 
processing  time,  the  storage  capacity  constraint  and  network 
reliability. 
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The  network  will  use 
a  source  routing  procedure. 
There  are  three  general  cases 
involving  packet  routing: 
single  addressee,  multiple 
addressees    or    messages 

addressed  to  all  users.   For 

Figure  6     Overview      of      the 
single-subscriber   addressed  store-and- forward  process 

packets,  once  a  message  has 

been  delivered,  processor  storage  space  is  made  available. 

For  messages  addressed  to  multiple  users,  a  separate  listing 

must  be  maintained  to  mark  deliveries  in  accordance  with 

packet  headers.   These  messages  may  be  held  for  long  periods 

of  time. 

Regarding  the  storage  constraint,  as  available  memory 

dwindles,  an  auto-dump  capability  ought  to  be  implemented, 

freeing  space  for  new  messages.    For  effective  storage 

management,  packets  need  to  be  prioritized  in  some  way, 

duration  of  time  in  storage  for  example,   so  that  some 

proportion  of  the  total  number  of  messages  are  deleted.   This 

brings  to  light  the  matter  of  network  accountability  in  an 

acknowledged  connectionless  service.   Once  the  SCU  accepts  a 

message,  it  becomes  responsible  for  delivery  of  that  message. 

Packets  which  are  dumped  due  to  storage  limitations  restricts 

the  level  of  network  reliability. 
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Although  straightforward,  this  communications  network 
has  very  densely  interrelated  operating  charcteristics .  A 
challenge  in  modeling  and  simulating  this  system  is  to 
identify  design  considerations  which  may  limit  operation  or 
which  may  be  altered  to  enable  improved  performance.  An 
enumeration  of  the  items  of  interest  and  a  discussion  of  the 
model  follows. 
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II.   ENUMERATION  OF  DESIGN  ISSUES 

In  attempting  to  create  a 

network  which  performs  well 

across  the  areas  of  channel 

access,   communications  flow 

and  packet  handling,  several 

questions  of  interest  have 

Figure  7  PANSAT  Network  Design 

emerged.  Designers  of  PANSAT  Issues 

expect  that  decisions  in  building  the  system  show  significant 
improvement  of  performance  measures  across  a  broad  array  of 
scenarios.  Particularly,  decision  makers  seek  enhancement  in 
channel  access,  decrease  in  session  duration  and  firm 
assessment  of  SCU  memory  requirements.  These  concerns  are 
enumerated  by  the  following  issues  and  partial  listing  of 
applicable  design  considerations: 

•  probability  of  channel  access  as  a  function  of  maximum 
synchronization  sequence  length,  data  transfer  rate,  the 
number  and  distribution  of  waiting  times  before 
retransmission  attempts; 

•  session  duration  as  a  function  of  maximum  synchronization 
sequence  length,  data  transfer  rate  and  maximum  (or  fixed) 
packet  length; 

•  SCU  storage  requirements  as  a  function  of  maximum  packet 
length  and  user  population  density. 

As  may  be  determined  from  this  list,  there  is  a  strong 

interdependence  among  the  design  issues  and  operational 

considerations.  In  fact,  the  three  areas  of  activity,  access, 
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flow  and  store-forward, 
affect  one  another.  Channel 
access  can  be  expected  to  be 
facilitated  by  shorter 
sessions.  In  turn,  higher 
rates  of  channel  access  may 

cut  down  on  variability  of 

Figure  8   Influential    network 
the  maximum  amount  of  SCU  design   factors 

memory  in  use.   To  establish 

the  model  as  a  credible  decision  aid,  these  issues  must  be 

formally  defined,  analyzed  and  simulated.   This  chapter  lays 

out  decision  makers'  questions  of  interest  and  measures  used 

in  making  the  determination. 

A.   CHANNEL  ACCESS 

For  PANSAT's  network  to  be  successful,  users  must  be 
furnished  with  reasonable  opportunity  to  capture  the  server. 
This  may  be  measured  by  the  proportion  of  users  obtaining  a 
lock  during  the  first  attempt,  and  during  subsequent  retries. 
Capture  is  affected  by 

•  maximum  number  of  repetitions  of  the  synchronization 
sequence; 

•  data  transfer  rate; 

•  discipline  governing  retries. 

The  channel  access  problem  may  be  interpreted  as  follows. 
Given  a  number  of  callers  who  simultaneously  have  the 
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The  channel  access  problem  may  be  interpreted  as  follows. 
Given  a  number  of  callers  who  simultaneously  have  the 
satellite  in  view,  how  many  attempts,  on  average,  are  required 
to  be  able  to  conduct  successfully  a  session  with  the 
spacecraft.  Alternately,  what  proportion-  of  users  are 
successful  on  the  first  attempt  and  then  on  each  subsequent 
attempt . 

Underlying  the  whole  channel  access  question  is  the 
concern  that  the  system  operator,  the  Naval  Postgraduate 
School,  be  assured  access  to  the  server.  Network  design 
decisions  may  be  implemented  to  enhance  that  prospect,  but 
may  be  found  inadequate  under  the  best  circumstances.  In  this 
case,  other  means  should  be  developed  for  activation. 

1.   Synchronization  Discipline 

There  is  no  feedback  marking  the  achievement  of  lock 
by  any  transmitter's  spreading  code.  The  user  receives  no 
indication  of  success  in  capturing  the  server's  receiver  until 
at  least  after  transmitting  the  identification  preamble 
following  the  synchronizing  sequence.  Given  an  idle  server, 
capture  after  the  full  128  iterations  of  the  spreading  code  is 
almost  assured;  as  will  be  shown,  the  SCU  is  captured,  on 
average,  in  64  iterations.  A  lower  cap  not  only  reduces  the 
excess  time  spent  transmitting  the  spreading  sequence,  but  in 
the  event  of  a  busy  server,  also  allows  for  fewer  delays  in 
initiating  subsequent  retries. 
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2.  Bit  Rate 

It  is  obvious  that  an  increase  in  data  transfer  rate 
will  most  likely  shorten  the  duration  of  a  session;  doubling 
the  bit  rate  may  halve  session  lengths.  Designers'  interest 
in  this  relationship  between  bit  rate  and  channel  access 
reflects  the  notion  that  shortening  the  duration  of  a  session 
will  increase  users'  access  to  the  server.  Other  factors  are 
not  specifically  under  the  engineers'  control.  These  include 
the  effect  of  the  number  of  collocated  users  concurrently 
desiring  access  or  the  ramifications  of  increased  bit  .error 
rate.  As  determined  by  the  engineers'  communications  network 
link  analysis,  two  feasible  data  transfer  rates  are  1200  and 
2400  bits  per  second  (bps) .  However,  either  the  expected  bit 
error  rate  may  increase  or  the  link  margin  may  decrease  for 
the  higher  data  transmission  rate  (Morgan,  1989,  p.  471)  .  The 
question  is  whether  the  higher  bit  rate  significantly  improves 
the  likelihood  of  a  user  accessing  the  server  despite 
increased  probability  of  bit  error. 

3 .  Retransmission  Regimen 

After  transmitting  the  synchronization  signal, 
identification  preamble  and  bit  packet,  the  subscriber  is  in 
either  of  two  states .   The  user 

•  is  engaged  in  a  session  with  the  spacecraft  control  unit 
if  the  server  is  idle; 

•  will  need  to  retransmit  the  entire  sequence  if  the  server 
is  busy. 
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In  the  event  of  retransmission,  what  should  govern  the 
amount  of  time  to  wait  and  the  number  of  retries?  From  a 
network  management  perspective,  the  goal  is  to  allow  for  the 
largest  number  of  users  to  access  the  channel.  This  might 
encourage  continual  retransmissions  until  success  is  obtained. 
On  the  other  hand,  it  is  important  to  preserve  some  circuit 
discipline  and  minimize  noise  contributed  by  other  users' 
transmissions  for  access  to  the  channel.  Resolution  of  this 
question  will  be  implemented  in  a  protocol  allowing  for  the 
highest  access  rate  coupled  with  the  minimum  number  of 
attempts . 

B.   SESSION  DURATION 

In  the  communications  flow  paradigm,  the  spacecraft  spends 
a  significant  proportion  of  time  in  a  captured  state.  This  is 
directly  analogous  to  the  busy  server  in  a  queueing  system. 
Of  interest  is  how  the  duration  of  these  busy  periods  vary 
with  the  implementation  of  a  full-  or  half-duplex  channel,  the 
data  transmission  rate,  packet  size,  and  bit  error  rate. 

The  duration  of  user  sessions  directly  impacts  the  number 
of  users  who  may  actually  gain  access  to  the  net  in  a  finite 
period  of  time.  So,  to  a  large  extent  the  design  parameters 
and  questions  enumerated  for  channel  access  also  apply  to  the 
session  duration  problem.  First  and  foremost  is  the  decision 
to  implement  a  full-  or  half -duplex  net.  In  this  context, 
engineers  may  then  determine  the  direction  to  pursue  regarding 
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the  synchronization  process,  bit  rate  and  maximum  packet 
length. 

1.  Duplex  vs.  Half-Duplex 

Nominally,  the  sequence  of  events  required  to  ensure 
a  successfully  completed  half-duplex  session  is  longer  and 
more  complicated  than  that  for  the  same  session  on  a  full- 
duplex  circuit.  The  key  concept  is  that  all  events  in  a  half- 
duplex  channel  are  serially  arranged.  In  a  full-duplex  net, 
some  of  these  events  occur  simultaneously.  Recall,  however, 
that  the  transmitted  power  is  spread  over  half  of  the  band- 
width in  a  full-duplex  channel,  because  the  net  allows  for 
simultaneous  communications  in  both  directions.  Contending 
users'  transmissions  may  contribute  greater  noise  to  the 
environment  than  in  a  half -duplex  net.  Sessions  may  be 
conducted  over  a  circuit  subject  to  the  higher  bit  error  rate 
resulting  from  the  potentially  noisier  environment.  A 
question  of  interest  is  whether  the  implementation  of  a  full- 
duplex  network  results  in  significantly  shorter  sessions 
regardless  of  the  bit  error  rate. 

2 .  Packet  Length 

Shorter  packet  lengths  mean  shorter  sessions.  Not 
only  because  the  subscriber  uplinks  shorter  messages,  but  all 
those  stored  for  download  are  also  shorter.  Furthermore, 
shorter  packets  have  a  smaller  probability  of  experiencing  bit 
error  than  longer  packets.    This  further  eliminates  the 
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occurrence  of  sessions  extended  due  to  retransmitting  lost 
data . 

It  is  preferred  to  limit  communications  as  little  as 
possible,  however.  Placing  too  restrictive  a  constraint  on 
packet  length  may  impede  a  subscriber's  utilization  of  the 
network.  The  engineers'  objective  is  to  allow  for  as  high  an 
upper  bound  on  packet  size  as  feasible  while  preserving  the 
goal  of  minimizing  session  duration. 

3 .   Spreading  sequence  and  data  transfer  rates 

Pertaining  to  session  duration,  these  two  design 
issues  have  a  similar  impact  as  discussed  regarding  channel 
access.  Engineers  are  interested  in  determining  how  much  the 
synchronization  sequence  must  be  shortened  to  significantly 
decrease  the  duration  of  a  session.  Again,  it  is  somewhat 
apparent  that  doubling  the  data  transfer  rate  will  shorten  a 
typical  session.  But,  is  this  enough  to  overcome  any  loss  in 
the  margin  of  the  link  analysis?  PANSAT's  designers  want  to 
know  if  doubling  the  data  rate  results  in  significantly 
shorter  sessions  despite  a  higher  bit  error  rate. 

C.   SCU  STORAGE  REQUIREMENTS 

The  driving  force  behind  PANSAT  is  its  utility  as  an 
experimental  platform.  Engineers  are  concentrating  on 
designing  the  spacecraft  to  establish  the  operability  of  this 
low-orbit  communications  network.    Still,  the  storage  of 
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packets  poses  a  design  problem.   SCU  memory  used  for  packet 
storage  varies  with  the  number  of  users  and  packet  size. 

It  is  important  to  consider  that  over  the  course  of  its 
lifetime,  interest  in  PANSAT  may  grow  to  the  extent  that 
design  limits  on  storage  capacity  may  be  flexed  to  the  limit. 
For  example,  the  satellite's  software  designers  claim  that  the 
SCU's  operating  system  will  be  altered  significantly  if  the 
storage  size  exceed  500  kilobytes  of  data.  Is  this  much  space 
required  or  will  this  level  be  exceeded?  Design  matters  here 
must  show  robustness  over  a  spectrum  of  resolution, 
introducing  greater  variability  in  storage  levels. 

To  determine  what  storage  capacity  to  design  for  the 
spacecraft  control  unit's  memory,  engineers  are  interested  not 
only  in  a  specific  measure  such  as  the  average  or  maximum 
level  of  storage  used.  Designing  based  upon  an  average  does 
not  reflect  the  range  over  which  the  running  total  walks.  As 
packets  are  received  and  are  downloaded,  observing 
fluctuations  in  storage  level  will  generate  a  mean  value;  the 
estimator  gives  no  information  on  the  proportion  of 
observations  which  exceed  this  point,  or  the  frequency  with 
which  they  do  so.  Similarly,  measuring  the  high-water  mark, 
the  maximum  level  reached  by  the  SCU's  memory,  provides  no 
description  regarding  how  often  this  occurs.  In  any  case,  the 
measure  of  interest  is  the  amount  of  memory  in  use  at  the  time 
of  the  next  packet's  receipt. 
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Decision  makers  want  to  know  the  distribution  of  memory 
used.  From  a  design  standpoint,  the  principle  factors  in  this 
density  are  the  number  of  users  allowed  to  participate  in  the 
net  and  determining  the  maximum  packet  length.  These  two 
parameters  may  be  readily  used  in  an  analytical  solution. 
However,  the  frequency  with  which  SCU  storage  varies  over  a 
range  of  values  is  very  much  scenario  dependent.  For  a  given 
number  of  subscribers  and  packet  size  selection,  designers 
want  the  SCU  to  accommodate  a  reasonable  proportion  of  the 
total  number  of  messages  over  a  number  of  diverse  scenarios. 

D.   HOW  A  MODEL  HELPS 

In  summary,  a  partial  listing  of  influential  design 
parameters  follows: 

data  transmission  rate  ; 

user  population  and  population  density  distribution  ; 

bit  error  rate  ; 

minimum,  maximum  and  fixed  packet  length  ; 

synchronization  attempt  discipline  ; 

SCU  storage  capacity  ; 

full-  or  half -duplex  communications. 
Complications  arise  in  trying  to  assess  the  interdependency  of 
these  design  factors  and  their  effect  on  the  network.  With 
this  level  of  complexity,  as  depicted  in  Figure  9,  what  kind 
of  numbers  may  be  generated  by  a  model?  How  will  the  observed 
simulated  activity  differ  from  specified  probability  models 
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simulated  activity  differ  from  specified  probability  models 
applied  to  each  question  of  interest? 

For  the  model's  results 
to  be  credible,  a  high  degree 
of  resolution  must  be 
incorporated  in  the 
representation  of  network 
communications.  In  analyzing 
the  system  and  creating  the 
objects  which  will  emulate 
the  flow  of  activity,  certain 
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characteristics  emerge  which  Figure  9  First    (solid  arcs)   and 

second     order (hollow)      effects 
suggest    a    common-sense  are  densely  related. 

approach    or    analytic 

probability  model  both  of  which  may  resolve  a  design  issue 

more  quickly  and  as  effectively  as  a  simulation  run.   The 

model's  three  levels,  common  sense,  analytic  and  simulation/ 

complement  each  other. 

For  each  measure  of  performance,  obtaining  expected  values 

may  be  consistent  between  the  probability  models  and  the 

simulation.   However,  as  a  descriptor  of  performance,  the 

average  value  falls  far  short.   In  essence,  the  merit  behind 

thorough  representation  of  network  activity  is  the  insight 

into  system  variability  afforded  the  decision  maker.   This  is 

where  the  anticipated  divergence  is  between  computer  runs  and 

paper  or  blackboard  results.   In  any  event,  the  working  model 
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major  design  decisions  which  may  be  further  substantiated  by 
a  high-resolution  simulation. 
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III.   INTRODUCTION  TO  THE  MODEL 

This  communications  network  may  be  modeled  with  a  great 
deal  of  fidelity  as  a  complicated  stochastic  model  implemented 
in  a  simulation.  The  simulation  is  written  in  reusable, 
object-oriented  code  so  that  other  design  issues  may  be 
explored  experimentally  and  so  that  new  studies  can  be  pursued 
as  scenarios  are  developed  by  PANSAT's  sponsors.  Accompanying 
probability  models  are  incorporated  to  validate  the 
simulation. 

The  simulation  contains  user  objects  which  act 
independently  and  the  SCU  object  which  stores  and  retrieves 
packets.  The  model  also  explicitly  emulates  the 
synchronization  process  and  full  conduct  of  a  user-SCU  session 
both  in  full-  and  half-duplex.  After  a  brief  outline  of  the 
principal  objects  in  the  model,  a  more  detailed  discussion  of 
the  model  design  follows. 

A.   MODEL  OBJECTS 
1 .   Users 

The  network  is  activated  by  users  attempting  to 
capture  the  satellite.  They  are  uniquely  identified  by  the 
following  attributes: 

•  callsign,  for  addressing  purposes  ; 

•  synchronization    attempt    process,    dictating    the 
interattempt  waiting  period  and  number  of  retries  ; 


26 


•  location,  either  isolated  or  collocated  in  a  population 
center. 

The  model  accounts  for  these  essential  characteristics  as  well 

as  the  user's  network  activities  by  creating  each  user  as  an 

autonomous  object.   In  this  regard,  operations  of  these  users 

are  encapsulated  in  a  series  of  object  methods  which  define 

their  impact  on  the  network,  summarized  in  Figure  10. 

Channel  access,  packet  flow  and  message  handling,  are 

significantly  affected  by  subscriber  actions.    Successful 

synchronization  causes  the  SCU  to  become  busy  and  conduct  a 

session.    Subscribers  generate  messages.   Message  size  and 

frequency  of  generation  affect  both  the  duration  of  the 

session  as  well  as  storage  by  the  SCU.   Transmission  of  the 

packet  requires  the  passage  of  time.   This  influences  the 

session  duration  and  in  turn  affects  other  subscribers' 

ability  to  access  the 

net.       A    user's 

traffic  receipt 

process      has      several 

ramifications      across 

the  network. 

Successful  receipt  of 

packets    from    the 

spacecraft  completes 

the  end-to-end  packet 

Figure  10  User  activity  affecting   the 
flow  and  also  allows  network's     state     includes     generating 

packets   and     attempting  net   access. 


Subscribers 

Fields 

are  objects 

callsign,  location, 

which  fully 

window  size ; 

emulate 

network  users. 

Methods 

synchronizes  Of 

^      unsuccessful,  attempts 

Ik     again),  generates 

if  packets,  transmits 

H  traffic  to  SCU,  receives 

H  stored  packets, 

^   provides  ACK/NACK, 

requests  disconnect. 

27 


the  SCU  to  free  storage  space  for  future  use.  If  packet 
receipt  is  obstructed  by  bit  error,  session  durations  become 
extended  and  endpoint-to-endpoint  communications  flow  may  be 
disrupted.  Finally,  the  procedures  of  acknowledging  and 
requesting  disconnect  prompt  the  end  of  a  session  and  close 
the  loop  on  packet  flow.  These  essential  activities  were 
selected  for  inclusion  in  the  model  because  they 

•  fully  describe  the  network  activity  of  the  users; 

•  affect  the  state  of  the  network  in  all  areas,  channel 
access,  communications  flow  and  packet  handling; 

•  preserve  a  high  level  of  resolution  in  the  model  by 
reflecting  actual  network  operation. 

2.   Spacecraft  Control  Unit 

The  SCU  object  contains  two  sub-objects,  the  user 
interface  and  message  storage  area.  These  two  entities  have 
attributes  and  procedures  which  allow  for  fully  analyzing  the 
SCU  and  its  role  in  the  network.  Figure  11  illustrates  the 
relevant  aspects  of  both  the  processor  and  storage  units. 

The  message  processor  is  the  user  interface.  As 
discussed  in  the  network  description,  it  drives  the  session 
with  the  active  user.  When  the  SCU  object  conducts  a  session, 
it  waits  for  packet  transmission  by  the  active  user,  commands 
all  packet  storage  and  retrieval,  manages  any  acknowledgement 
procedures  and  terminates  the  session.  In  short,  it 
completely  emulates  PANSAT's  network  communications. 
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SCU: 
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storage,  orbit  duration; 
Methods 
drives  session,  receives 
traffic,  synchronizes,  sends 
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terminates  session ; 
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S  imi larly,  the 
storage  object  within  the 
spacecraft  module  mimics  all 
salient  features  of  PANSAT's 
SCU  storage.  Once  commanded 
by   the   control   unit,   the 

storage    manipulates    the 

Figure  11  List  of     attributes 
messages  and  identifies  all  owned    and    procedures     carried 

out   by   the   SCU. 
packet    addressees    by 

callsign.   The  amount  of  packet  storage  space  utilized  is 

readily  monitored;  the  value  may  be  accessed  at  any  time. 

These  features  fundamentally  cover  the  activity  of  the  storage 

unit  in  network  operations. 

3 .   Bit  Packet 

The   characteristics 

which  define  a  unique  packet 

are  shown  in  Figure  12 .   Just 

as  in  the  actual  network,  the 

bit   packet   is   generated, 

transmitted    to     the 

spacecraft,  received,  stored 


BltPackfttQbjftct 

bit  packets  ate  fully  defined  by^ 

originator's  callsign 

addressee's  callsign  (a  record) 
for  muting  purposes,  will 
flag  if  destined  for  all  users 
identify  group  callsign  or 
identities  subscriber  as  addee 

bit  size  of  packet  (including  header) 

time  of  transmission 


Figure  12  The  bit  packet 
and  retrieved  and  downlinked  object  exhibits  all 

characteristics  of  actual 
to  the  destination.    It  is  packets   in   the  network. 

subject  to  bit  error  at  ends 

of  the  communications  flow.   Once  the  packet  is  routed  to 
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storage,  space  is  allocated;  upon  forwarding,  space  is 
deallocated. 

All  network  operations  which  influence  the  movement  of  bit 
packets  are  reflected  with  a  high  degree  of  fidelity  in  the 
model.  This  is  essential  to  the  model's  utility  in  decision 
making.  Properties  of  the  model  which  prove  crucial  to  its 
ability  to  properly  imitate  the  network  are  discussed  in  the 
next  section;  these  are  followed  by  a  listing  of  network 
features  implemented  in  PACSIM. 

B.   MODEL  FIDELITY  AND  RESOLUTION 

To  create  a  credible  model,  a  number  of  concepts  relevant 
to  network  analysis  must  be  incorporated  in  the  simulation. 
Simulation  is  a  unique  tool,  allowing  the  decision-maker  to 
view  the  model  network  operation  under  varying  conditions. 
The  model  includes  flexibility  in  a  number  of  areas  which 
impact  the  questions  of  channel  access,  packet  storage  and 
endpoint-to-endpoint    connectivity.       They    include: 

•  capturing  the  SCU; 

•  packet  generating  environment; 

•  occurrence  of  bit  error; 

•  geographically  sensible  population  density  distribution; 

•  dynamics  of  a  low-orbit  spacecraft. 

These  processes  have  consequences  throughout  the  network. 
Although  some  assumptions  are  made,  the  idea  is  to  minimize 
the  model's  dependence  on  them  by  incorporating  as  much  of  the 
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known  communications  structure  as  possible.  This  allows  for 
substantial  benefits  in  consistency  of  results  across  varied 
input  assumptions. 

1 .   Capturing  the  SCU 

The  amount  of  accuracy  built  into  this  process  is 
applied  on  three  levels.  Synchronization,  initial  attempts  at 
access  and  subsequent  retries  are  subprocesses  which  define 
the  fidelity  of  capture. 

a.  First  Attempt 

When  the  spacecraft  comes  into  view  for  a  user, 
there  is  a  non-zero  probability  that  it  is  busy.  The  model 
allows  engineers  to  choose  the  delay  between  the  first  moment 
a  user  has  the  spacecraft  in  view  and  the  time  the  user  first 
attempts  synchronization.  For  an  arbitrarily  selected  user, 
the  first  attempt  at  channel  access  may  occur  after: 

•  an  insignificantly  small  time  interval; 

•  a  random  period  of  time  which  is  of  the  same  distribution 
as  any  interattempt  distribution; 

•  a  random  interval  according  to  a  pre-arrival  distribution 
which  is  different  than  that  of  the  ensuing  interattempt 
periods . 

Modeling  the  first  attempt  as  any  of  these  has  varying 
advantages  and  disadvantages . 

Because  the  spacecraft  comes  into  view  at  a  known 
time,  it  is  reasonable  to  expect  that  the  initial  attempt  will 
occur  within  some  small  period  of  time.    This  is  easy  to 
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model.  The  case  in  which  the  first  attempt  follows  a  waiting 
period  which  is  of  the  same  distribution  as  the  interarrival, 
or  backoff,  periods  is  also  straightforward  but  not  realistic. 
It  is  not  reasonable  to  expect  the  typical  user  to  wait  some 
extended  random  interval  prior  to  the  first  attempt.  The  last 
paradigm  is  the  most  realistic  but  difficult  to  model  because 
selection  of  this  unique  pre-arrival  distribution  is 
arbitrary. 

Jb .  Synchroni zation 

An  attempt  to  capture  the  idle  SCU  is  not 
necessarily  successful  because  the  satellite's  receiver 
discriminates  based  upon  the  spreading  sequence,  not  the  order 
of  arrival  (Pursely,  1987,  p.  116)  .  The  spacecraft's  receiver 
will  start  to  correlate  itself  with  the  first  subscriber's 
attempt.  However,  if  a  subsequent  synchronization  is  more 
closely  aligned  with  the  receiver,  this  will  capture  the  SCU 
first . 

If  the  uplinked  128  bit  spreading  code  is  not 
correlated  with  the  satellite's  expected  string,  the  receiver 
slides  one  bit  and  checks  again.  The  best  case  is  achieving 
a  lock  without  requiring  retries;  the  worst  is  128  iterations 
of  the  spreading  code  before  lock.  Because  the  user  can  not 
be  assured  of  achieving  a  lock  until  all  iterations  are 
complete,  the  synchronizing  protocol  encourages  transmission 
of  the  maximum  number  of  repetitions.  As  discussed,  a  cap  may 
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be  placed  on  the  maximum  number  of  iterations  of  the  spreading 
code  to  be  transmitted.  This  level  of  accuracy  is  available 
in  the  model .  PACSIM  accounts  for  capturing  the  receiver 
before  completion  of  the  spreading  sequence.  Once  in  lock, 
the  SCU  beomes  busy,  but  actual  conduct  of  the  session  is 
delayed  until  the  balance  of  the  spreading  code  has  been 
transmitted.  If  the  cap  has  been  attained,  synchronization 
ceases,  irrespective  of  whether  the  receiver  has  been 
captured. 

c.   Retries 

If  the  first  synchronization  attempt  is 
unsuccessful,  the  subscriber  waits  an  interattempt  backoff 
period.  This  is  a  random  interval  established  by  the 
communications  protocol.  The  reason  for  randomness  in  backoff 
is  to  preclude  multiple  users  from  backing  off  in  lock-step. 
Typical  distributions  for  backoff  are  exponential, 
arithmetic,  and  geometric  among  others.  After  the  random 
wait,  another  synchronization  is  attempted  and  the  SCU  will 
again  be  found  either  busy  or  not.  The  decision  maker  may 
select  the  backoff  period  distribution  as  well  as  the  number 
of  retries  allowed  per  user, 

2.   Packet  Generating  Environment 

To  accurately  reflect  potential  network  activity  ,  it 
is  important  to  minimize  assumptions  and  to  implement  expected 
characteristics  in  the  model.   Because  packet  creation  and 
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routing  is  at  the  crux  of  the  operations,  it  is  particularly- 
important  to  impose  a  high  degree  of  fidelity  in  the  following 
areas  which  comprise  the  packet  generating  environment: 

•  packet  generation; 

•  packet  sizing; 

•  packet  addressing. 

Specific   elements   of   the  packet   generating   environment 
implemented  in  PACSIM  are  listed  in  the  next  section. 
a.    Packet   Generation 

There  are  several  schemes  available  in  modeling 

Impact  of  Packet  Generation  on  the  Model 

process  event  time 

ORBIT  ! (     ) (      )--> 

view  view 

NEED  TO 

GENERATE  | A > 

need 

generated 

USER'S 

SESSION  1 x x > 

will  only  will  also 

download  generate  and 

stored  transmit 

traffic  traffic 

1  Outline  of  a   user's  message  generation  requirement. 

this  aspect  of  the  network.  One  dictates  that  all  users 
continually  have  a  need  to  enter  messages  into  the  network. 
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This  will  aid  in  simulation  model  validation.  Users  attempt 
to  access  the  net  and  transmit  a  packet  for  handling  by  the 
SCU.  This  is  the  heaviest  traffic  generating  paradigm.  The 
circumstances  for  this  will  arise  in  the  course  of  spacecraft 
operations,  but  may  not  be  present  in  the  actual  network  in 
equilibrium. 

More  reasonably  are  the  following  approaches  for 
modeling  subscribers'  need  to  communicate: 


•  deterministic  --  after  specified  intervals,  a  day  for 
example,  a  generating  mission  arises; 

•  probabilistic  --  this  paradigm  establishes  a  random  period 
of  time  between  missions.  These  periods  may  be  very  long, 
influenced  by  the  total  user  population,  independent  and 
memoryless;  this  suggests  the  use  of  a  gamma  distribution 
in  defining  inter-generation  intervals;  this  is  the 
probability  distribution  used  in  PACSIM; 

•  scripted  --  specified  scenarios  envisioned  for  packet 
generation  ought  to  be  implemented  for  analysis. 


If  the  user  has  the  spacecraft  in  view,  an  attempt  is  made  to 
establish  a  session  and  generate  a  packet  for  entry  into  the 
system.  If  the  spacecraft  is  not  in  view,  then  the  caller 
waits  until  the  communication  window  opens  and  then  proceeds 
as  described  above.  Once  the  packet  generating  mission  has 
been  initialized,  the  issue  of  sizing  and  addressing  the 
packet  come  into  play. 

b.    Packet   Length 

PANSAT's  engineers  want  to  place  as  few  constraints 
as  possible  on  packet   length  to  allow  subscribers   the 
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opportunity  to  communicate  an  unrestricted  quantity  of 
information.  Because  of  a  slow  data  transfer  rate  in  the 
network  and  finite  communications  windows  as  well  as  protocol 
restrictions,  a  finite  maximum  packet  length  will  be 
implemented.  How  can  one  best  express  the  actual  distribution 
of  the  packet  size? 

By  design,  the  model  should  be  robust  enough  such 
that  the  choice  of  distribution  will  alter  the  face  of  the 
model  imperceptibly.  Because  there  are  minimum  and  maximum 
bounds  on  message  length,  the  actual  packet  size  may  be 
considered  uniformly  distributed  between  these  limits.  This 
covers  a  large  proportion  of  the  packets  generated  and 
accommodates  enough  variability  that  the  realistic  packet 
lengths  are  included. 

c.    Packet  Addressing 

By  default  a  model  may  be  created  in  which  packet 
addressing  is  equiprobably  distributed  among  all  users.  This 
is  straightforward  for  developing  a  probability  model  to 
validate  the  simulation  but  stretches  the  notion  of  realistic 
packet  addressing. 

More  reasonable  is  the  idea  that  some  users  are 
much  more  likely  to  be  addressed  in  a  packet  than  others. 
Superusers,  such  as  the  Naval  Postgraduate  School,  the  network 
system  operator,  can  expect  to  receive  a  significant 
proportion  of  the  traffic.   Likewise,  more  packets  will  be 
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exchanged  within  geographic  regions  or  other  social  groupings 
of  users.  Finally,  the  recipient  of  a  packet  may  be  likely  to 
transmit  another  packet  to  the  first  message's  originator. 
These  packet  volleys  may  persist  for  several  exchanges.  All 
of  these  are  readily  set  in  motion  in  the  simulation  and 
provide  a  great  amount  of  fidelity  with  a  minimum  of 
assumptions . 

3 .   Occurrence  of  Bit  Error 

The  probability  of  error  occurring  in  data 
transmission  is  principally  a  function  of  signal-to-noise 
ratio.  The  derived  bit  error  rate  in  the  link  analysis  is 
0.00001  errors  per  bit  (Panholzer,  1992,  p.  3).  Multiple 
users  transmitting  simultaneously  create  increased  noise  in 
the  radio-frequency  environment,  thus  increasing  the  bit  error 
rate.  Occurrences  of  bit  error  may  be  in  the  header,  the 
information  packet  or  both.  Error  in  the  header  may  cause 
loss  of  the  entire  packet;  error  in  the  information  frame  may 
cause  a  loss  of  data;  error  in  both  may  also  cause  loss  of  the 
packet . 

At  the  user  and  spacecraft  receivers,  the  packet  is  to 
be  sampled  for  the  occurrence  of  bit  error.  Because  error 
does  not  occur  independently  among  bits,  representation  of  Pe, 
the  probability  of  bit  error,  is  given  by  a  uniform  sampling 
of  the  bit  packet.  For  example,  a  1000  byte  information 
packet,  consisting  of  8000  bits  of  data,  Pe  [packet] =0 . 0800 . 


37 


On  a  round  trip  from  user  to  spacecraft  to  addressee,  the 
probability  that  this  packet  experiences  bit  error  is  0.1536. 
This  has  the  following  implications  for  the  network: 

•  to  preserve  data  flow,  retransmissions  will  be  required  ; 

•  channel  access  may  be  restricted  due  to  extended  sessions; 

•  network  reliability  will  deteriorate  if  the  protocol  does 
not  ensure  end-to-end  communications  to  a  certain  level. 

All  of  these  ramifications  of  bit  error  are  included  in  the 
simulation  model. 

4.   User  population  distribution 

Decision  makers  have  sought  to  identify  the  potential 
user  base  for  PANSAT  in  order  to  substantiate  design 
decisions.  Initial  survey  results  showed  a  tremendous  amount 
of  enthusiasm  for  the  program,  predominantly  in  high 
population  density,  metropolitan  regions.  Unfortunately, 
enthusiasm  in  a  survey  does  not  necessarily  map  accurately 
into  active  participation  in  a  financially  capital-intensive 
network.  Simulation  may  be  the  superior  course  of  action  in 
assessing  network  performance  over  various  user  population 
densities . 

For  model  validation,  subscribers  are  uniformly 
distributed  over  the  orbit  of  the  spacecraft  as  is 
characteristic  of  a  Poisson  process.  This  archetype  is 
suitable  if  the  following  are  true: 
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•  orderly  arrivals  --  users  attempt  to  access  the  net  one  at 
a  time  ; 

•  stationarity  --  the  distribution  of  the  number  of 
attempts  made  is  a  function  solely  of  the  time  interval 
investigated  and  is  independent  of  when  this  interval 
starts ; 

•  lack  of  after-effects  --  the  number  of  attempts  in  a  given 
interval  is  independent  of  the  number  in  previous  and 
subsequent  disjoint  intervals. 


Based  on  the  network  description  in  chapter  one,  the 
first  assumption  is  plausible.  The  credibility  of 
stationarity  is  questionable  when  examining  the  behavior  of 
the  network  in  its  full  orbit.  Some  population  centers  are 
more  dense  than  others.  Intervals  including  activity  in  these 
user  bases  might  differ  significantly  from  observations  of 
others.  However,  among  collocated  users,  stationarity  may  be 
a  reasonable  supposition.  During  the  period  when  collocated 
subscribers  hold  the  spacecraft  in  view,  the  intensity  of 
users  attempting  to  access  the  network  may  be  consistent  among 
disjoint  sub-intervals.  The  third  assumption  required  for  a 
Poisson  process  does  not  hold. 

Disjoint  time  intervals  are  not  independent.  All  are 
tied  to 


•  session  duration;  extended  sessions  are  highly 
interdependent  and  severely  impede  channel  access . 
Reattempts  add  to  the  number  in  contention  during 
subsequent  intervals  and  packets  for  download  accumulate 
in  the  SCU.   The  consequence  is  more  extended  sessions  ; 

•  the  number  of  users;  with  a  small  number  of  collocated 
users,  each  successfully  completed  session  results  in 
fewer  attempts  to  capture  the  SCU  in  future  intervals. 
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This  indicates  some  correlation  between  the  number 
attempting  channel  access  in  one  interval  and  the  number 
in  subsequent  intervals. 


Within  a  population  center,  it  is  reasonable  to  assume 
orderliness  and  stationarity  among  subscribers  contending  for 
channel  access.  It  is  more  difficult  to  justify  all  Poisson 
assumptions  of  stationarity,  orderliness  and  independent 
increments  for  the  spacecraft's  complete  orbit. 

5.   Network  Characteristics  of  a  Low-orbit  Spacecraft 

Subscribers  are  collocated  in  population  centers. 
During  certain  orbits,  the  spacecraft's  footprint  may  cover 
more  than  one  of  these  regions  concurrently.  This  reflects 
what  is  expected  in  actual  operations  of  a  low-orbit  satellite 
communications  system.  PANSAT  will  have  a  bounded  footprint 
allowing  only  a  portion  of  the  users  access  at  any  given  time. 
Furthermore,  the  sinusoidal  nature  of  its  orbit  creates  a 
situation  in  which  users  will  not  necessarily  have  a  view  of 
the  spacecraft  for  most. 

Periodicity  in  the  spacecraft's  orbit  also  yields 
varying  window  durations.  A  user  will  have  the  spacecraft  in 
view  for  an  interval  lasting  between  four  and  ten  minutes, 
depending  on  the  position  of  the  satellite  in  its  orbit. 
Combined  with  the  variability  of  session  duration,  the  channel 
access  problem  becomes  more  realistic.  These  dynamics  have 
implications  throughout  the  network  and  are  implemented  in 
simulation. 
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C.   WHAT  WAS  AND  WHAT  WAS  NOT  IMPLEMENTED 

To  effect  the  level  of  accuracy  described  in  the  previous 
section,  the  following  were  implemented: 


•  the  first  attempt  was  modeled  to  follow  a  very  small 
period  of  time  after  the  spacecraft  comes  into  view  of  a 
population  center; 

•  the  proportion  of  users  selecting  to  attempt  access  during 
an  orbit  is  input; 

•  a  cap  on  the  number  of  synchroniation  iterations  is 
established  as  an  input  parameter; 

•  the  exponential  backoff  algorithm  was  used,  but  the  mean 
backoff  time  is  an  input  parameter; 

•  the  choice  of  the  packet  generating  modes  is  available; 
the  probabilistic  approach  makes  use  of  a  gamma 
distribution  shaped  by  the  number  of  users  and,  as  with 
the  deterministic  mode,  the  rate  of  generation  is  input  by 
the  modeler; 

•  the  lifetime  of  packet  generating  missions  is  also 
selected  by  input; 

•  packet  length  is  determined  by  a  uniform  sampling  of  an 
interval,  the  upper  bound  for  which  is  input,  enabling 
emulation  of  fixed  packet  lengths  by  setting  the  bounds 
equal ; 

•  packet  addressing  is  divided  into  the  proportion  of 
messages  to  be  addressed  to  the  Naval  Postgraduate  School, 
a  superuser,  the  proportion  to  be  addressed  within  the 
goegraphic  area,  and  those  to  be  addressed  to  any  user  in 
the  network;   these  proportions  are  input; 

•  the  bit  error  rate  is  input; 

•  the  number  of  user  population  centers,  their  locations, 
geographic  size,  and  number  of  users  are  input; 

•  finally,  PANSAT's  orbit  periodicity,  identification  of 
location's  views  during  a  period,  as  well  as  minimum, 
maximum  and  average  footprint  durations  are  input. 
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In  addition,  some  elements  of  a  high-resolution  representation 
of  the  network  were  not  used.   These  include: 


group  broadcast  in  which  a  single  message  is  routed  for 
all  or  a  group  of  users; 

building  a  superuser  object  who  would  have  the  ability  to 
address  single  messages  to  groups  of  users; 

selecting  the  maximum  number  of  synchronization  retries; 

using  a  sinusoidal  function  to  determine  the  occurrence 
and  duration  of  spacecraft  views; 

the  ability  for  the  model  to  read  an  input,  scripted 
network  scenario; 

implementating  protocol-specific,  such  as  AX. 25  or  TCP-IP, 
communications  activity; 

differentiating   among   modem-specific   synchronization 
processes  aside  from  the  rate  of  achieving  lock. 


The  level  of  model  accuracy  has  been  firmly  established. 
Although  some  elements  of  network  activity  have  not  been 
exactly  implemented  in  simulation,  the  model  has  established 
a  level  of  credibility  such  that  solutions  provide  very  high 
confidence  guidelines  for  making  design  decisions.  A  list  of 
verification  experiments  and  results  are  presented  in  the  next 
chapter. 
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IV.     PACSIM  VERIFICATION  AND  MODEL  VALIDATION 

To  ensure  that  the  simulation  model  "operates  in  the  way 
that  the  model  implementer  thinks  it  does"  (Bratley,  1987,  p. 
8) ,  PACSIM' s  evolution  as  a  simulation  program  has  been  marked 
by  a  process  of  verification.  "Verification  is  determining 
that  a  simulation  computer  program  performs  as  intended  . . . 
[and]  checks  the  translation  of  the  conceptual  simulation 
model  (eg.  flowcharts  and  assumptions)  into  a  correctly 
working  program."  (Law,  1991,  p.  299)  This  chapter  outlines 
the  techniques  and  procedures  used  in  verifying  PACSIM  as  a 
program  and  validating  it  as  a  model. 

A.   MODULAR  PROGRAMMING,  DEBUGGING  AND  TESTING 

PACSIM  is  separated  into  more  than  40  distinct  modules, 
compiled  individually  and  linked  as  a  program.  The  initial 
manifestation  of  PACSIM  featured  one,  two  and  three  user 
scenarios  and  traced  the  entire  process  of  channel  access, 
session  conduct  and  message  storage  and  forwarding  of  a 
motionless  spacecraft.  Once  a  very  high  degree  of  confidence 
in  the  model  was  obtained,  larger  user  population  scenarios 
were  used.  Sensible  output  was  confirmed  as  each  of  the 
following  improvements  and  levels  of  resolution  were  added: 


•  cities  --  determining  if  contention  among  users  was  being 
resolved  properly; 
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•  orbits  --  ensuring  that  users  could  attempt  access  to  the 
SCU  only  when  the  spacecraft  was  in  view; 

•  proportion  of  users  attempting  access  --  checking  for  user 
synchronization  attempts  during  the  appropriate  views; 

•  packet  generating  environment  --  confirming  that  each  of 
the  different  packet  generating  schemes  and  missions  had 
the  correct  impact  on  system  activity;  for  example,  the 
further  the  model  departed  from  the  heavy  traffic 
generating  scenario,  both  SCU  storage  levels  and  average 
session  durations  decreased. 


B.   VARYING  PARAMETERS  AND  SENSITIVITY  TESTING 

The  following  is  a  partial  list  of  parameters  whose  values 
were  changed  in  validating  PACSIM's  performance: 

number  of  users; 

number  of  cities; 

packet  length  bounds; 

data  transfer  rate; 

bit  error  rate; 

proportion  of  users  attempting  access  to  the  SCU; 

spacecraft  orbit  periodicity; 

number  of  views  per  spacecraft  orbiting  period; 

full-  or  half -duplex  sessions; 

backoff  rates; 

the  maximum  number  of  synchronization  iterations. 

Experiments  have  generated  a  wide  range  of  values  for  system 
performance  measures  by  varying  these  parameter  inputs.  The 
results  are  discussed  in  the  following  chapter.   Analysis 
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yielded  the  conclusion  that  varied  inputs  led  to  changes  in 
not  only  the  measures  themselves  but  their  variability  as 
well . 

C.   CHECKING  AGAINST  KNOWN  SOLUTIONS 

The  model  was  run  "under  simplifying  assumptions  for  which 
its  true  characteristics  are  known  (Law,  1991,  p.  303)."  An 
analytical  model  has  been  applied  to  the  following  issues  in 
the  PANSAT  network: 


•  establishing  the  average  number  of  messages  in  SCU  storage 
in  equilibrium; 

•  characterizing   session   durations   by   a   distribution 
function; 

•  treatment  of  the  channel  access  problem  as  a  single  server 
system  with  no  queue. 


The  results  provide  a  foundation  for  verifying  simulation 
results . 

1 .   Number  of  Packets  in  Storage 

For  the  analytical  model  of  this  issue,  the  following 
assumptions  are  made: 

•  there  are  N  independent,  identical  users; users  access  the 

•  network  no  more  than  once  an  orbit; 

•  addressee  selection  is  equiprobable  among  all  users,  that 
is  P[packet  is  addressed  to   a  specific  user]  =  1/(N-1). 
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To  make  PACSIM  simulate  this  tractable  model,  the  following 
features  wre  altered: 

•  the  spacecraft  is  in  view  for  the  entire  run; 

•  all  users  are  located  in  a  very  small  interval; 

•  sessions  are  modified  to  require  a  minimum  amount  of  time 
to  prevent  second-order  influence  on  the  statistic  of 
interest;  specifically,  data  transfer  rate  is  at  2400 
baud,  packets  are  no  longer  than  100  bytes  and  a  full- 
duplex  channel  is  used; 

•  the  default,  heavy  communications  traffic  flow  scenario  is 
used; 

•  addressing  is  uniform  among  all  users. 

a.  The  Tractable  Model 

The  first  objective  is  to  define  the  distribution 
of  the  equilibrium  number  of  messages  being  stored  by  the  SCU 
for  an  arbitrarily  selected  user. 

For  any  user,  there  may  be  k  messages  in  storage, 
for  any  k  =  0,  1, ....  The  only  transitions  which  may  occur 
are  as  listed  in  Table  1  and  depicted  in  Figure  13.  In  all  of 
the  cases  outlined  in  Table  1,  the  status  of  the  future  state 
of  the  mailbox  is  fully  determined  by  the  transition 
probabilities  from  the  current  state  space.  Because  this  is 
simple  system  Markovian,  the  probability  distribution  for  k 
may  be  readily  derived.  Letting  7tk  represent  the  equilibrium 
probability  that  a  user  has  k  messages  being  stored  by  the 
SCU, 

7ln  =  — — 7ln  +  —  7*,+  —  71, +  —  7t,+  .   .  . 

0       N°NlNzN3 
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Table  1.   TRANSITIONS  FOR  NUMBER  OF  USER'S  MESSAGES  IN  SCU 

Transition 

Probability 

Explanation 

k  to  (k  +  1) 

1/N 

P[pkt  sent  to  i  1  a  user 
other  than  i  arrived]  = 
(1/(N-1)  )  (  (N-D/N) 

k  to  k 

(N-2) /N 

P[pkt  not  sent  to  i  1  a  user 
other  than  i  arrived]  = 
(  (N-2) /(N-l)  )  (  (N-D/N) 

k  to  0 

1/N 

P[i  arrives] 

0  to  0 

(N-l) /N 

P[{i  visits  an  empty  mailbox} 
n  {pkt  not  sent  to  i}  1  {user 
other  than  i  arrived}]  =  1/N 
+  (N-2)/N 

which  may  be  written  as 


o   N      °    N     ° 

where  7C^0  is  the  probability  of  one  or  more  messages  are  being 
stored.   This  yields  two  equations  and  two  unknowns: 


K0    +    7C,0  =  1 


and    7t0  -  ft-,o  =  0 
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1/N 

^O/N 

1/n(          J  1/N 
(N-2)/N 

/^^~"~~                       ~~~^\ 

^^j  1/N      M        1/N   f) 
(N-1)/N             (N-2)/N             (N-2)/N 

Figure  13  State  space  and  transition  probabilities  for  the 
number  of  messages   in   the  SCU  for  an  arbitrary  user. 

these  two  equations  yield  the  stationary  probability  that  the 
user  has  no  messages  in  SCU  storage,  KQ   =  1/2  and  the  rest 
are  as  follows: 


— _7tn  +  — r^Tti-Tti^TtT^  —  Tl< 


N 


N 


—  TC,+ 
N   x 


N-2 
N 


7l2=7l2=>7l2  =  -7l1=(-)27r( 


or  in  general,  K,  the  equilibrium  number  of  messages  in 
storage  for  an  arbitrarily  selected  user  is  a  geometric  random 
variable  with  parameter  p  =  1/2  and  k  =  0,  1,  ....  The 
expected  value  is 


E[K]  =-^=1.000 
P 
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with  variance 

V[K]  =  -^-=2.000 
P2 

b.    PACSIM  Results 

Confirmation  of  the  geometrically  decaying  number 
of  messages  stored  for  a  user  is  provided  in  Table  3 .  PK  is 
the  proportion  of  users  with  K  messages  in  SCU  storage  and  nk 
is  the  equilibrium  probability  that  there  are  k  messages  being 
stored.   Furthermore,  the  estimated  expected  value 


E[K\    =  J2  k  $k   =  0.999  *  1.000 


k  =  0 


Table  2   CONFIRMING  THE  DISTRIBUTION  FOR  THE  NUMBER  OF  A 
USER'S  MESSAGES  IN  SCU 

K 

0 

1 

2 

3 

4 

5 

6  + 

Pk 

.502 

.226 

.138 

.075 

.034 

.011 

.012 

KK 

.500 

.250 

.125 

.063 

.031 

.016 

.015 

and  the  estimated  variance 

V[K\    =  £[K2}    -    {E![K]  )2  =  2.926   -  0.998  =  1.928  *  2.000 

compare  very  favorably  with  the  analytical  result. 
2.   Expected  Session  Duration 

To  verify  the  expected  session  duration,  sessions 
extended  due  to  message  retransmissions  should  be  eliminated 


49 


from  PACSIM's  outcomes.  The  following  simulation  features 
were  altered  to  provide  a  scenario  for  verifying  session 
duration  distribution: 


•  bit  error  rate  was  reduced  to  zero,   precluding  the 
occurrence  of  bit  error  and  any  retransmissions; 

•  all  other  elements  of  PACSIM  were  implemented  in  the  full- 
duplex  communications  channel  scheme. 


a.  Tractable  Model 


event 

duration 

balance  of  spreading 

cc 

de 

uniform  random 

identification  pream] 

Die 

fixed 

user  mes 

sage  upload 

uniform  random,   given 
a  need  to  generate 

SCU  ackn 

owledgement 

fixed 

user  ret 

ransmissions 

uniform  random,  given 

bit  error  occurrence 

SCU  mess 

age  download 

geometric  number  of 
uniform  random  periods 

user  acknowledgement 

fixed 

SCU  retransmissions 

uniform  random,  given 
bit  error  occurrence 

2  Enumeration     of    a     session     as     a     series     of    independent 
events . 

The  full  duplex  session  is  a  series  of  random  and 
fixed  length  subevents,  enumerated  in  the  box  above.  It  is  a 
sequence  of  fixed  values  and  random  variables .   The  expected 
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duration  of  the  session,  St,  is  the  sum  of  the  expected  values 
of  the  lengths  of  the  subevents.  The  computation  of  these 
values  are  listed  below. 


event 

balance  of  spreading  code 
identification  preamble 
user  message  upload 

SCU  acknowledgement 
SCU  message  download 

user  acknowledgement 


expected  duration 

E  [synchronization  duration] 

constant 

E[size  of  message  in  bits] 
x  transmission  rate 

constant 

E [number  of  messages  stored] 
x  E[size  of  message] 
x  transmission  rate 

constant 


3  Listing  of  expected  values   of  session   subevents . 

b.    PACSIM  Result 

Computing  the  time  required  for  downloading 
messages  from  the  SCU  invoked  Wald's  equation.  The  expected 
amount  of  data  for  transfer  in  equilibrium  is  the  expected 
number  of  messages  for  download  multiplied  by  the  expected 
value  of  the  size  of  these  messages.  The  expected  size  of  the 
messages  is  based  upon  the  assumed  uniform  distribution  for 
message  length.  Determining  the  expectation  of  session 
durations  provides  insight  into  error-free  performance  of  the 
network.   This  result  has  direct  ramifications  for  treatment 
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of  the  tractable  model  as  a  queuing  system,  as  will  be  shown 
in  the  next  section.  As  can  be  seen  in  Table  3  ,  all  session 
durations  observed  in  PACSIM  are  within  two  percent  of  the 
tractable  model's  result. 


Table  3.   COMPARING  EXPECTED  AND  OBSERVED  SESSION  LENGTHS 

Communications  Channel  Settings 

Analytical 

Observed 

12  00  Baud,  2Kbyte  Maximum  Length 

15.47 

15.63 

2400  Baud,  2Kbyte  Maximum  Length 

7.57 

7.45 

12  0  0  Baud  1Kbyte  Maximum  Length 

8.13 

7.96 

1200  Baud,  1Kbyte  Fixed  Length 

14.13 

14.33 

3 .   Channel  Access  as  a  Queueing  Problem 

For  a  tractable  queuing  model  to  be  simulated  the 
following  factors  were  implemented: 


•  users   access   attempts   were   distributed   as   Poisson 
arrivals ; 

•  user  synchronization  attempts  are  sure  events; 

•  there  are  no  population  centers,  the  spacecraft  is  in  view 
for  the  entire  run,  with  the  footprint  covering  all  users; 

•  all  other  elements  of  a  full-duplex  system  were  used  to 
emulate  the  M/G/l  queue. 


a.  Tractable  Model 

PANSAT's  engineers  want  users  to  have  ready  access  to 
the  network.  Because  there  is  only  one  channel  for  conducting 
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sessions  and  users  must  synchronize  with  an  idle  SCU  to 
capture  it,  the  channel  access  problem  may  be  viewed  as  a 
queueing  problem.  Specifically,  channel  access  occurs  when 
the  server  is  idle.   The  probability  that  the  SCU  is  idle, 

Pidle'       1S 

X 


Pidle      =      1    ' 


=      1    - 


=      1    - 


E[ session  duration] 
E[interat tempt  interval. 

E[SC] 


E[Ta] 

where  X  is  the  rate  of  users  attempting  to  access  the  SCU  and 
|I  is  the  reciprocal  of  the  mean  session  duration.  Sc  is  the 
session  duration,  and  Ta  is  the  interattempt  interval.  To 
increase  channel  access,  engineers  will  seek  to  shorten 
session  length  or  increase  backoff  periods. 
b.    PACSIM     Results 

These  verification  experiments  situated  between  50 
and  400  users  randomly  over  a  5500  second  orbit.  Because 
Poisson  arrivals  see  time  averages,  the  ratio  of  orbit 
duration  to  number  of  users  yielded  the  mean  interattempt 
interval.  In  Table  4,  Pidle  reflects  the  tractable  model's 
solution,  while  Pobs,  the  proportion  of  users  accessing  on  the 
first  attempt,  is  given  in  the  bottom  row.  The  observations 
confirm  results  of  the  tractable  model.  This  further  verifies 
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the   model   as   an   accurate   representation   of   PANSAT's 
communications  network. 


Table    4.     FIRST   ATTEMPT   CHANNEL   ACCESS    AS    A   QUEUING    SYSTEM 

Number   of   Users 

50 

100 

150 

200 

300 

400 

E[St] 

8.38 

8.27 

8.14 

8.25 

8.28 

8.38 

E[Ta] 

110.0 

55.0 

36.6 

27.5 

18.3 

13.8 

Pidle 

.924 

.850 

.778 

.700 

.548 

.391 

p 

*■  obs 

.985 

.843 

.776 

.703 

.572 

.398 
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V.   PACSIM  RESULTS 

A.   DATA  COLLECTION 

PACSIM  ran  nearly  200  different  scenarios  to  explore  the 
design  questions  enumerated  in  Chapter  II.  All  observations 
were  recorded  during  steady  state  in  order  to  evaluate  the 
system's  long-run  behavior.  Session  duration  and  channel 
access  observations  were  measured  at  the  completion  of 
transactions  while  SCU  memory  observations  were  taken  when 
messages  were  being  received  by  the  SCU.  The  following 
experiments  were  run: 

•  measuring  the  quantity  of  SCU  storage  used  with  a  1000  and 
2000  byte  maximum  message  length  while  increasing  the 
number  and  population  density  of  subscribers; 

•  comparing  half-duplex  channel  and  full-duplex  channel 
session  durations,  at  a  data  transmission  rate  of  1200 
baud  under  varying  bit  error  rates; 

•  comparing  full-duplex  session  durations  at  data 
transmission  rates  of  1200  and  2400  baud  under  varying  bit 
error  rates; 

•  measuring  session  durations  with  maximum  message  lengths 
of  1000,  2000  and  4000  bytes; 

•  measuring  session  durations  with  the  maximum  number  of 
synchronization  sequence  repetitions  set  at  128,  96  and  64 
iterations ; 

•  identifying  the  rate  of  channel  access  at  data  transfer 
rates  of  1200  and  2400  baud  in  a  full-duplex  circuit; 

•  comparing  the  rate  of  channel  access  while  varying 
exponential  backoff  rates  of  15,  30,  45  and  60  seconds;  - 
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•  identifying  the  rate  of  channel  access  while  varying  the 
maximum  number  of  synchronization  sequence  iterations 
among  12  8,  9  6  and  64. 


B.   SCU  Storage 

PANSAT's  designers  sensed  that  an  increased  number  of 
users  and  larger  maximum  message  sizes  require  a  greater 
quantity  of  SCU  storage.  PACSIM  confirmed  these  ideas  and 
provided  further  insight  into  this  design  issue.  Figure  14 
summarizes  the  conclusions  as  follows: 


Average  Quantity  of  SCU  Storage  Used 
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Figure  14    Average  amount     of     SCU    storage     used     as     a 
function   of   user  population   and  maximum  message   length. 


•  in  a  heavy  message  traffic  scenario  and  2000  byte  maximum 
message  length,  the  initial  500  kilobyte  memory  threshhold 
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set  by  the  communications  designers  becomes  an  issue  when 
there  are  more  than  3  00  users  in  the  network;  the  envelope 
is  pushed  further  out  for  the  1000  byte  message  limit; 

•  variability  in  the  quantity  of  memory  used  increases  with 
increased  user  population  density;  all  experiments  used 
four  population  centers  --  increased  channel  contention  is 
associated  with  a  decreased  rate  of  access,  creating  an 
opportunity  for  messages  to  accumulate  in  storage; 

•  for  the  2  000  byte  maximum  message  length,  memory  usage 
increases  superlinearly  with  the  number  of  users;  this 
corroborates  the  idea  that  channel  access  is  linked  to  SCU 
memory  usage . 


This  measure  reflects  only  one  scenario  for  network  user 
activity.   Observations  ought  to  be  made  when 

•  message  generation  is  less  intense; 

•  users  exercise  the  option  not  to  access  the  SCU  ; 

•  a   greater  proportion  of  messages   are   addressed  to 
superusers . 

C.   SESSION  DURATION 

Efforts  to  shorten  session  lengths  and  increase 
communications  duty  cycles  are  concentrated  on  shifting  from 
a  half-  to  full-duplex  circuit,  increasing  bit  rate, 
shortening  maximum  message  length  and  truncating  the 
synchronization  process.  These  sessions  were  run  under  the 
heavy  message  generating  environment,  in  which  users  uploaded 
a  message  and,  on  average,  downloaded  one  message. 
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1.   Full-Duplex  vs  Half -Duplex 

Originally,  PANSAT  was  to  utilize  a  half-duplex 
communications  circuit.  When  the  decision  was  made  to  focus 
engineering  efforts  on  a  full-duplex  channel,  shorter  sessions 
were  expected  to  occur.  PACSIM  revealed  several  other 
ramifications  of  this  design  decision,  as  shown  in  Figure  15: 
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Figure  15   Comparison    of    full-    and    half -duplex    channel 
average  session   duration  as  a   function  of  bit   error  rate. 


•  full-duplex  is  very  robust  against  increases  in  bit  error 
rate; 

•  full-duplex  sessions  have  a  significantly  smaller  rate  of 
increase  in  duration  as  bit  error  increases; 

•  due  to  a  greater  number  of  prolonged  sessions,  half -duplex 
experiences  more  variability  as  bit  error  increases; 
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•  on  average,  full-duplex  sessions  are  shorter,  even  at  bit 
error  rates  exceeding  three  times  that  of  half-duplex 
sessions . 


2.   1200  Baud  vs  2400  Baud 

Developing  PACSIM  gave  rise  to  discussions  on  the 
effectiveness  of  a  half -duplex  circuit.  Once  engineers 
started  thinking  in  terms  of  operability  of  the  network,  the 
next  step  was  to  consider  increasing  the  data  rate.  Figure  16 
depicts  the  obvious  improvement  in  shortening  the  average 
session.  Additionally,  the  following  conclusions  may  be 
drawn : 
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Figure  16  Comparing  effects  of  1200  baud  and  2400  baud 
full-duplex  channels  on  average  session  duration  as  a 
function   of  bit    error. 
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•  2400  baud  communications  are  even  more  robust  against  bit 
error  than  the  1200  baud  data  transmission  rate; 

•  increases  in  session  duration  are  almost  insignificant 
even  at  a  bit  error  rate  four  times  the  bit  error  rate 
assumed  in  the  link  analysis; 

•  if  the  assumed  link  margin  remains  constant,  the  2400  baud 
circuit  outperforms  the  1200  baud  circuit  at  a  signal  to 
noise  ratio  which  allows  for  quadruple  the  bit  error  rate. 

3 .   Packet  Length 
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Figure  17  Comparison   of   session   durations    using  maximum 
message  length  as   the  parameter . 

Engineers  expect  that  restricting  the  maximum  length 
of  messages  requires  less  transmission  time  and  yields  shorter 
sessions.  In  addition,  longer  messages  have  a  greater 
probability  of  incurring  bit  error  which  extends  sessions  due 
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to  retransmissions.   PACSIM  substantiates  these  notions,  as 
shown  in  Figure  17;  other  conclusions  include: 


•  75  percent  of  sessions  exchanging  messages  limited  to  1000 
bytes  require  fewer  than  25  seconds;  on  the  other  hand,  50 
percent  of  the  2000  byte  message  exchanges  and  75  percent 
of  the  4000  byte  transfers  exceed  25  seconds; 

•  larger  messages  for  transfer  yield  much  more  variability 
in  session  duration; 

•  average  session  duration  under  greater  maximum  message 
lengths  shows  significant  increase,  but  provides  little 
insight  into  their  distributions. 


In  lighter  message  generating  schemes  or  under  higher  data 
tranfer  rates,  differences  may  be  less  pronounced. 
4.   Synchronization  Protocol 
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Figure  18  Session  duration 
distributions  as  a  function 
of   synchronization  protocol . 
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Figures  18  and  19  depict  the  distribution  of  session 
durations  while  varying  the  maximum  number  of  synchronization 
iterations.   The  following  conclusions  may  be  drawn: 


•  because  of  the  relatively  short  duration  of  this  process, 
varying  the  synchronization  protocol  has  little  impact  on 
the  duration  of  sessions; 

•  there  is  no  significant  difference  in  session  duration 
even  if  the  maximum  number  of  synchronization  iterations 
is  cut  in  half. 


If  the  primary  purpose  of  altering  synchronization  protocol  is 
to  shorten  sessions,  there  is  nothing  to  be  gained  as  shown  by 
the  insignificant  difference  in  results. 

D.   CHANNEL  ACCESS 

As  discussed,  design  decisions  with  respect  to  channel 
access  revolve  around  the  following  issues: 


•  the  likelihood  that  the  Naval  Postgraduate  School  will  be 
able  to  access  the  SCU  unimpeded; 

•  reduction  in  the  number  of  attempts  users  make  to  access 
the  spacecraft  --  with  each  try,  more  noise  is  created  on 
the  channel ; 

•  what  proportion  of  users  can  expect  to  access  the 
spacecraft . 


The  engineers  can  improve  overall  channel  access  by  shortening 
the  duration  of  sessions  or  increasing  the  interval  between 
users  attempt  at  capturing  the  SCU.  Specifically,  PACSIM  ran 
scenarios  measuring  channel  access  against  changes  in  bit 
rate,  backoff  rate  and  synchronization  protocol. 
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1.   Bit  Rate 

Figure  20  depicts  channel  access  as  a  function  of  data 
transfer  rate.  It  has  been  shown  that  an  increase  in  data 
rate  significantly  shortens  session  duration.  Of  particular 
note : 
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Figure  20  Probability   of   successful    channel    access    for   a 
given  attempt   as  a   function  of  data   transfer  rate. 


•  even  at  three  times  the  bit  error  rate,  channel  access  is 
significantly  better  in  a  2400  baud  circuit  than  one  at 
1200  bits  per  second; 

•  at  2400  bits  per  second,  overall  channel  access  is  90 
percent  successful  after  eight  attempts,  while  this  level 
of  success  is  attained  after  14  tries  in  a  1200  baud  net. 
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2 .   Backoff  Rate 

According  to  the  analytical  result  for  this  issue,  as 
the  interattempt  period  is  increased,  the  rate  of  channel 
access  improves.  This  experiment  used  a  half -duplex  net  at 
1200  bits  per  second  and  a  bit  error  rate  of  10E-6.  The 
average  session  duration  for  this  scenario  is  30  seconds. 
PACSIM  shows  this  improved  channel  access,  but  in  addition,  it 
is  evident  that: 


Proportion   of   Users   Accessing    SCU 

o 

BACKOFF         RATE 

CO 

o 

O 

m 

en 
1) 
u 
u 

3 
t/1 

ID 

o 

0 

m 

a 

a. 

o 

CM 

O 

/sy^C^^                                                                                            x    60sec   Backoff   Rate 
v>>-^^                                                                                                         +    45sec   Backoff   Rate 
w                                                                                                                      A    30sec   Backoff   Rate 

o 
o 

0    15sec   Backoff   Rate 

1  1                           1                          1                           1                           1                           1 

2  4                               6                               8                              10                            12                            14 

Number   of   Attempts 

Figure  21  Probability  of  successful    channel   access   for  a 
given   attempt    as   a    function   of  backoff  rate. 


•  there  is  no  significant  difference  in  successful  first 
attempts ; 
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•  session  duration  creates  an  upper  bound  on  the  success  of 
retries ; 

•  a  backoff  protocol  in  which  users  continually  retry  at 
intervals  much  shorter  than  the  expected  session  length 
show  poor  rates  of  success . 


3.   Synchronization  Protocol 

P AC SIM  shows  that 
altering  the  synchronization 
protocol  has  no  significant 
effect  on  channel  access. 
This  further  shows  the  point 
that  session  duration  drives 
channel  access.  Even  though 
the  synchronization  sequence 
was  truncated  to  the  point  at 
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process,  success  rates  changed  insignificantly. 
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VI.   SUMMARY  AND  CONCLUSION 

A.   SPACECRAFT  NETWORK  DESIGN 

PANSAT's  engineers  are  designing  a  satellite 
communications  network  to  operate  in  an  environment 
characterized  by  uncertainty.  From  PANSAT's  onset,  designers 
were  developing  a  half-duplex,  1200  baud,  store-forward  system 
to  accommodate: 

•  a  user  base  unknown  in  number,  location  and  population 
distribution; 

•  random  network  activity; 

•  arbitrary  message  generating  and  addressing; 

•  impediments  to  connectivity  such  as  the  occurrence  of  bit 
error  or  an  inability  to  capture  the  SCU. 

The  goal  was  to  design  a  functional  spacecraft  for  this  highly 
unpredictable  communications  flow.  The  first  step  was  to 
identify  PANSAT's  operational  characteristics. 

By  establishing  a  paradigm  of  network  activity, engineers 
were  able  to  concentrate  on  operations  despite  the  random 
environment.  We  specified  channel  access,  communications  flow 
and  SCU  storage  as  the  fundamental  network  elements.  This 
highlights  the  simplicity  of  the  communications  network  but 
provides  little  insight  into  the  strong  interdependence  of 
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design  issues  and  fails  to  reflect  the  extensive  impact  of 
uncertainty  on  operability. 
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Figure  23  summarizes  the 

nominal  flow  of  information 

from  users  to  the  SCU  and 

back  to  users.  Nodes  signify 

concurrent  network  activity, 

arcs  depict  the  flow  of  data. 

User  activity,  the  source  of 

Figure  23  Flow  of  information 
the  data  flow  is  subject  to  through    the   PANSAT  network. 

the  uncertain,  bursty,  non-stationary  nature  of  communications 

networks.   What  happens  to  the  flow  of  messages  when  the 

number  of  users  varies,  network  activity  changes,  or  message 

addressing  is  altered?   System  performance  becomes  entirely 

scenario  dependent.  Flow  from  preceding  states  determines  the 

nature  of  communications  at  subsequent  points.   Successful 

spacecraft  network  design  takes  these  features  into  account. 

B.   PACSIM'S  DEVELOPMENT 

Once  the  network's  underlying  complexity  was  established, 
PACSIM  was  developed  to  emulate  the  system's  communications 
and  to  provide  a  basis  for  comparing  design  decisions  among 
different  scenarios.  "When  a  simulation  model  and  its  results 
are  accepted  by  the  . . .  client  as  being  valid,  and  are  used  as 
an  aid  in  making  decisions,  we  call  the  model  credible. "  Law 
and  Kelton  provide  a  methodology  for  establishing  model 


67 


credibility  (Law,  1991,  pp.  299-310).    The  following  list 
documents  the  construction  of  PACSIM  as  a  decision  aid. 

•  Interaction  with  design  team:  When  PACSIM  was  initially- 
developed,  the  engineers'  focus  was  not  on  operational 
issues,  much  less  what  the  model  was  going  to  provide.  As 
results  emerged  which  confirmed  and  expanded  on  decision 
makers'  notions,  their  interest  and  involvement  in  PACSIM 
were  enhanced.  Decision  makers  provided  input  on 
treatment  of  bit  error,  flexibility  in  packet  generating 
and  user  selectivity  in  channel  access.  These  were 
incorporated  in  the  simulation  program,  further 
strengthening  its  validity. 

•  Structured  walk-through:  A  walk-through  document 
specifying  the  essential  elements  of  the  network  and 
outlining  all  network  activity  was  presented  to  the 
spacecraft  project's  principle  investigator,  project  lead 
and  systems  engineer.  The  meeting  resulted  in 
confirmation  of  model  assumptions,  awareness  of  network 
activity  and  guidance  for  PACSIM' s  development. 

•  Conversations  with  system  "experts":  In  addition  to  over 
250  hours  of  meetings  with  PANSAT's  engineers,  nearly  400 
hours  were  spent  researching,  discussing  and  studying 
network  communications.  Before  programming,  an  extensive 
analysis  of  network  design  indicated  the  need  to  reassess 
the  development  of  the  1200  baud,  half-duplex  system. 

•  Existing  theory:  There  is  a  voluminous  amount  of 
literature  available  on  packet  communications.  Queuing 
theory  applications  provided  strong  background  in 
identifying  the  stochastic  nature  of  a  network  and 
prompted  PACSIM' s  verification. 

•  Experience /In tuition:  PACSIM  pre-dates  the  network  it  is 
modeling;  in  addition,  PANSAT  will  be  a  unique  system. 
The  foundation  and  fidelity  of  the  model  is  backed  with 
over  75  years  of  spacecraft,  satellite  and  communications 
network  design  experience  of  the  engineering  team. 


C.   EVALUATING  PACSIM  AS  A  DECISION  AID 

The  crux  of  this  issue  is  credibility.  According  to 
Fossett,  et  al .  ,  the  level  of  confidence  in  a  simulation  model 
is  bolstered  by  its  ability  to: 
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•  reflect  and  take  as  input  important  features  of  the  system 
being  analyzed  and  its  environment; 

•  produce  results  that  make  sense; 

•  minimize  discrepancies  between  results  and  real-world 
observations  (Fossett,  1991,  p.  714). 


The  first  two  points  have  been  covered  in  Chapters  III  and  V. 
This  last  point  is  very  difficult  to  address  PANSAT's  network 
is  both  unique  and  not  yet  in  existence.  Instead,  the 
following  questions  may  apply  in  evaluating  PACSIM  as  a 
decision  aid  for  this  project: 

•  why  conduct  a  simulation  study? 

•  what  is  the  decision-making  environment? 

a.  Simulation  Study- 
Reasons    for  using  simulation  as  a  decision  aid  is 
based  on: 

•  characteristics  of  performance  measures; 

•  treatment  of  assumptions; 

•  number  of  scenarios  to  consider; 

•  complexity  of  PANSAT  operations; 

•  design  team's  confidence  in  PACSIM. 

PANSAT  performance  measures  are  highly  non- 
deterministic  and  have  no  applicable  data  for  analysis. 
Examination   required   a   model   which   incorporates   the 
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interdependent  design  issues  and  factors  as  well  as  the  random 
features.  The  study  is  particularly  suited  for  the  use  of  an 
object-oriented  program  to  specify  the  behavior  and  attributes 
of  important  network  features. 

The  input  data  and  distributions  selected  have  been 
previously  substantiated.  Packet  length  is  the  only  random 
input  which  may  not  duplicate  the  real-world  size 
distribution;  the  use  of  a  uniform  random  variable  provides 
enough  variance  to  cover  a  large  range  of  values  within  the 
established  bounds.  Proper  imitation  of  message  generating 
and  addressing  is  arbitrary.  A  goal  is  to  provide  the 
flexibility  to  balance  assumptions  with  the  ability  to  alter 
the  scenarios.  In  order  to  augment  engineers'  confidence  in 
the  model,  the  impact  of  probabilistic  assumptions  was 
minimized. 

Operation  of  PANSAT's  communications  network  will 
be  carried  out  in  a  multitude  of  environments.  Features 
include  varying  numbers,  locations  and  activities  of  users, 
noise-induced  bit  error  and  spacecraft  orbital 
characteristics.  Some  features  may  complement  each  others' 
effect  on  operability  while  others  may  be  neutral  or  opposite 
in  their  influence.  The  outcome  of  a  combination  of  any  two 
alterations  may  be  anticipated.  Network  performance  under 
several  features'  changes  is  much  less  intuitive  and  requires 
experimentation  through  simulation. 
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Finally,  the  network's  complexity  and  the  model's 
crediblity  make  PACSIM  a  valued  tool.  Identifying  the  nature 
of  PANSAT  operations,  confirming  and  measuring  the  design 
team's  intuitive  appraisals,  providing  meaning  to  performance 
variability,  and  elucidating  previously  unrecognized  system 
characteristics  have  strengthened  the  engineers'  ability  to 
make  design  decisions.  Specific  improvements  in  the  decision 
making  environment  are  presented  in  the  next  section. 
b.    Decision  Making  Environment 

The  decision  makers  are  engineers  with  vast 
experience  in  space  systems.  Conclusions  based  on  their 
intuition  benefit  from  a  working  knowledge  of  PANSAT' s  design 
issues.  PACSIM' s  first  step  toward  credibility  was 
confirmation  of  the  intuitive  assessments: 


•  a  larger  number  of  users  leads  to  increased  SCU  memory 
requirements ; 

•  shifting  from  half-duplex  to  full-duplex  or  increasing  the 
data  transfer  rate  shortens  sessions. 


The  next  step  was  to  provide  an  understanding  of  variability 
in  design  issues: 


•  increased  contention  for  the  SCU  yields  increased 
frequency  of  extended  sessions  and  larger  swings  in  SCU 
memory  used; 

•  longer  messages  not  only  increase  session  durations  but 
experience  greater  variability  in  session  duration  due  to 
retransmission  requirements. 
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This  also  allowed  for  discussions  of  significant  differences 
between  performance  measures  for  different  designs.  Finally, 
PACSIM  has  brought  to  light  several  issues  which  make  it  a 
useful  tool  for  satellite  network  design  and  analysis: 


•  Multiple  attempts  are  required  to  obtain  a  reasonable 
chance  of  accessing  the  SCU.  If  the  Naval  Postgraduate 
School  ground  control  center  wants  to  be  assured  of 
access,  some  other  means,  such  as  secondary  frequency  or 
coded  access,  will  need  to  be  implemented. 

•  Network  design  issues  and  factors  are  very  densely 
interrelated.  Session  duration  was  expected  to  have  a 
strong  effect  on  all  areas  of  communications  flow. 
However,  in  a  heavy  traffic  scenario,  it  has  emerged  over 
the  course  of  experiments  to  be  the  driving  force  behind 
channel  access  and  SCU  utilization. 

•  Efforts  to  shorten  session  duration  by  improvements  in 
effective  data  rate  make  the  network  more  robust  against 
bit  error. 


At  this  point  in  PANSAT's  development,  the  insight 
into  and  measurements  of  characteristic  network  performance 
under  various  design  decisions  and  operating  scenarios  cannot 
be  obtained  anywhere  else.  PACSIM  is  not  a  panacea,  however. 
Numerical  results  are  very  much  driven  by  scenario  and  cannot 
be  extrapolated  or  predicted  when  applied  to  others.  This  is 
the  reason  for  providing  multiple  levels  of  resolution  to  the 
model.  Unfortunately,  there  is  no  way  to  ascertain  whether 
enough  reality  has  been  implemented  or  if  the  correct 
scenarios  have  been  incorporated  in  the  simulation.  It  is 
difficult  enough  to  forecast  the  utilization  of  a  system  which 
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has  been  operated  previously.   PANSAT  will  be  the  first  of  its 
kind. 

In  any  event,  PACSIM  provides  a  structure  to  analyzing  the 
potential  operating  environment  of  PANSAT  and  a  means  of 
assessing  improvements  and  degradations  based  upon  design 
decisions.  This  tool  was  not  previously  available  to  the 
design  team.  A  model  is  a  foundation  and  sets  the  tone  for 
building  a  successful  network.  PACSIM  provides  a  window  on 
previously  unforeseen  communications  and  allows  the  engineers 
to  make  more  informed  decisions. 
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